AI文档生成实战：用Claude Code生成专业需求文档
你会学到什么
文档是开发者最耗时的非编码工作。需求评审要写PRD、技术评审要写方案、API上线要写文档、项目交付要写说明书。这些工作传统方式要花几小时甚至几天，而用AI工具配合合适的提示词，可以把时间缩短到几十分钟。
本节不讲大道理，直接上手三个实战：用Claude Code生成PRD文档、协作写技术方案、输出符合国标的Word文档。你还会学到什么时候需要用搜索工具补充信息、什么时候需要让AI"去AI化"、以及几个可以直接复用的文档模板。
为什么前端开发者需要AI生成文档
先看前端开发者在项目周期中要写的文档类型：
| 文档类型 | 典型场景 | 传统耗时 | AI耗时 |
|---|---|---|---|
| PRD（产品需求文档） | 需求评审前输出给团队 | 4-8小时 | 30-60分钟 |
| 技术方案 | 技术评审前输出给开发团队 | 4-6小时 | 30-60分钟 |
| API文档 | 组件或接口上线前 | 2-4小时 | 15-30分钟 |
| 组件使用文档 | 组件库或内部组件 | 1-2小时 | 10-20分钟 |
| 变更日志 | 版本发布时 | 30分钟-1小时 | 5-10分钟 |
传统写文档的痛点不在内容本身，而在格式和排版。打开Word调整页边距、设置标题级别、对齐表格、处理页码，这些非内容工作占了50%以上时间。更糟的是，文档写完容易过时——代码改了文档没改，多人协作文档版本混乱。
AI时代把这个流程倒过来了：你关注内容决策，格式和排版交给AI。PRD里有哪些章节、技术方案要包含哪些模块、API文档要怎么排版，这些AI都知道。你只需要把决策说清楚，剩下的生成、排版、导出都是自动的。
/docx Skill实战：生成需求文档
/docx是Claude Code内置的文档处理Skill，能把Markdown转换为符合规范的Word文档（.docx格式）。它支持标题层级、表格、目录、页眉页脚、批注等Word核心功能。
实战1：生成Vue3组件库的PRD文档
假设你要为一个新的Vue3组件库写PRD。不要直接问"帮我写一个PRD"，而是用结构化的提示词让AI知道你要什么。
请为我的Vue3组件库生成一份PRD文档，要求：
1. 文档结构：
一、项目背景
二、产品定位
三、目标用户画像
四、核心功能清单（表格形式）
五、技术方案概述
六、开发计划
七、风险评估
2. 项目信息：
- 项目名称：Vue UI
- 核心卖点：TypeScript原生 + 50KB核心包 + CSS变量主题
- 目标用户：个人开发者和小团队的中后台项目
- 技术栈：Vue 3.5、Vite 8、TypeScript 7、pnpm workspace
3. 输出要求：
- 先生成Markdown格式的PRD
- 检查内容无误后，用/docx导出为.docx格式
- 包含自动生成的目录
text
Claude Code会先生成Markdown内容，你需要检查确认。没问题后，调用/docx Skill：
/docx 将上面的PRD内容导出为Word文档，文件名：Vue-UI-PRD.docx
text
/docx会自动处理：
- 标题层级对应Word的标题样式
- 表格保持边框和对齐
- 生成自动目录
- 设置合理的页边距和行距
实战2：从TypeScript接口生成API文档
前端开发者经常要写组件API文档。如果组件已经定义了TypeScript接口，可以直接用AI生成文档：
// button.ts
export interface ButtonProps {
type?: 'primary' | 'default' | 'dashed' | 'text'
size?: 'small' | 'medium' | 'large'
disabled?: boolean
loading?: boolean
htmlType?: 'button' | 'submit' | 'reset'
onClick?: (event: MouseEvent) => void
}
export interface ButtonSlots {
default: () => VNode[]
icon?: () => VNode[]
}
typescript
把这个接口定义喂给AI：
基于下面的Button组件TypeScript接口，生成API文档：
【接口代码在这里】
输出格式要求：
1. 每个Props属性包含：类型、默认值、说明
2. 每个Slot包含：说明、使用示例
3. 包含3个完整的使用示例代码
4. 输出Markdown格式
text
生成的文档类似：
# Button 组件API文档
## Props 属性
| 属性名 | 类型 | 默认值 | 说明 |
|--------|------|--------|------|
| type | 'primary' \| 'default' \| 'dashed' \| 'text' | 'default' | 按钮类型 |
| size | 'small' \| 'medium' \| 'large' | 'medium' | 按钮尺寸 |
| disabled | boolean | false | 是否禁用 |
| loading | boolean | false | 是否加载中 |
| htmlType | 'button' \| 'submit' \| 'reset' | 'button' | 原生button type属性 |
| onClick | (event: MouseEvent) => void | - | 点击事件回调 |
## Slots 插槽
| 插槽名 | 说明 |
|--------|------|
| default | 按钮内容 |
| icon | 图标内容 |
## 使用示例
### 基础用法
\`\`\`vue
<Button type="primary">提交</Button>
\`\`\`
### 带图标
\`\`\`vue
<Button type="primary">
<template #icon><IconSave /></template>
保存
</Button>
\`\`\`
### 加载状态
\`\`\`vue
<Button loading>提交中...</Button>
\`\`\`
markdown
实战3：让AI对齐已有Word模板格式
直接把Markdown转成Word只能得到"默认样式"的文档，而真实交付场景往往是：公司有一套固定的Word模板（字体、字号、表格样式都不能动），要做的是往模板里填内容。/docx对此提供了一个关键能力：复制一份原文档，在原文档基础上直接编辑——原格式全部保留。
实操流程：
- 把模板文件（如 原格式.docx）放进工作目录
- 发这句提示词（最关键的是最后一句"在原文档基础上直接编辑"）：
按照这个格式，使用docx来完成，输出几个类似的表格到 示例.docx，
保持格式完全一致。使用copy复制一份原DOCX，
然后在这个基础之上直接编辑原文档。
text
- 先让AI随机生成三条示例数据，人工核对格式是否对齐：
你先随机产生三条示例数据，我看看是否与我的格式一致。
text
- 确认格式没问题后，再让AI写入真实内容
实测中AI会先解析原文档的样式（标题层级、字体字号、表格边框），再按同样式样新增内容。整个"解析+生成"过程视模型能力花了约18分钟，但格式基本能对上，个别细节（比如某列默认成了文本类型）微调即可。这十几分钟的等待换来整套模板格式的完整保留——手工在新文档里复刻一套模板样式，往往更慢。
这句提示词还能进一步封装：把"保持格式一致+复制原文档编辑"固化成自定义命令或Skill，下次一条指令触发（对应第3章的Commands与本章的Skills思路）。
导出时的注意事项
用/docx导出时，有几个常见问题需要注意：
- 代码块语法高亮：/docx导出的Word文档代码块是纯文本，没有语法高亮。如果需要高亮，导出后手动在Word中设置，或者考虑用Markdown格式交付。
- 表格宽度：自动导出的表格可能宽度不一致。在Word中选中表格，右键"自动调整"→"根据窗口自动调整表格大小"。
- 目录更新：导出后目录是静态的。修改内容后，在Word中右键目录→"更新域"→"更新整个目录"。
/doc-coauthoring Skill实战：协作写技术方案
/doc-coauthoring是专门为协作写文档设计的Skill，它提供了一套结构化的工作流：传递上下文→迭代完善→验证可读性。当你需要写一份多章节、长篇幅的技术方案时特别有用。
实战：协作写组件库技术方案
启动Skill后，它会引导你完成三个步骤：
/doc-coauthoring
第一步：传递上下文
请告诉我你要写什么文档、给谁看、需要包含哪些核心内容。
text
你的回答应该是结构化的：
文档类型：技术方案
文档名称：Vue UI组件库技术方案
目标读者：前端开发团队
核心内容：
1. 项目背景和目标
2. 技术栈选型和理由
3. 项目架构设计（monorepo结构）
4. 构建方案（Vite库模式）
5. 组件开发规范
6. 测试策略
7. 发布流程
text
接下来Skill会逐项收集更详细的上下文——团队规模、是否开源、框架版本、工程结构、样式方案、开发目标、借鉴对象、各维度的优先级打分，大约十个问题。逐条回答（示例）：
1. 团队有5人
2. 组件库开源
3. Vue 用最新版
4. 使用 monorepo
5. 没有使用 Tailwind CSS
6. 开发目标是内部使用，考虑发包
7. 借鉴 Element Plus 和 Naive UI
8. 性能优先级 5
9. 文档完善度 5
text
问题也可以按推荐默认值回答，不必每条都展开。收集完充足上下文后，Skill生成初稿。
Skill会进入第二步，生成初稿：
基于你提供的信息，我生成了以下技术方案初稿：
【生成的内容】
请检查：
1. 是否有遗漏的重要内容？
2. 哪些部分需要补充细节？
3. 哪些描述不够准确？
text
这一步你不需要一次改完。可以针对某个章节要求展开：
第3章"项目架构设计"太简单了，请补充：
1. packages目录下每个子包的职责
2. 包之间的依赖关系
3. 构建产物的目录结构
text
Skill会根据你的反馈迭代修改。最后是第三步，验证可读性：
文档内容已经确定。现在做可读性验证：
1. 假设读者是一个新加入团队的开发者，他读这份文档能理解我们要做什么吗？
2. 技术术语是否有解释？
3. 是否缺少必要的背景说明？
让我知道你需要调整的地方。
text
/doc-coauthoring的核心价值在于它把"一次性生成"变成了"协作式迭代"，每一步都在你的控制下，而不是AI盲目输出一堆内容。
/cn-docx Skill实战：中文技术文档去AI化
AI生成的文档有一种"AI味"：句子太整齐、用词太书面、缺少中文技术文档的惯用语。对内文档问题不大，但对外交付（给客户的方案文档、给甲方的需求文档）就需要处理。
/cn-docx Skill专门解决这个问题：它把Markdown转换为符合国标GB/T 8567-2006的Word文档，同时消除AI生成痕迹。
AI味长什么样：先看两个直观例子
不给任何提示词约束，直接让AI"输出一份PRD大纲"，得到的内容通常有这些特征：
- 满篇总结性语句（"综上所述""总而言之"），开头结尾都要升华一下
- 连词和序号过于标准：首先/其次/最后，一级二级标题嵌套得整整齐齐
- 标题起得很文艺："五大趋势""三足鼎立"这类表述不会出现在交付文档里
- 情态词分级泛滥："必须有""应该有""可以有"，写得像规范文书
再让它写一篇《UI组件库的行业现状与趋势》——即使环境里装了local-search、检索回来的内容足够新——输出还是带着无序列表套无序列表、文艺风小标题的毛病。内容能用，直接交付不行。
正文里的AI味更隐蔽。两个典型改写：
- "值得注意的是，我们需要特别关注性能优化的问题"→"性能优化是本方案的核心考量之一"。改写后有点老套、传统，但这才是交付文档的表达方式
- "显而易见，这个方案能够有效提升开发效率"→量化成"该方案预期可将开发效率提升30%"。交付文档不说"有效提升"，要给具体数字，量化才显得专业
/cn-docx Skill的创建过程：调研→固化→应用
/cn-docx不是现成安装的第三方包，而是用local-search调研、再让AI把调研结果固化成Skill——这个过程本身就是"不知道怎么做时"的通用方法论。
第一步：用local-search调研"AI味"。自己直接问AI"如何去AI味"，得到的答案不统一（AI未必知道什么叫AI味）；换成检索式调研，从网上把别人的实践经验收回来：
使用 local-search 搜索：什么叫AI味？
输出的文章有AI味如何去除AI味？
text
调研输出一份MD文档，核心内容包括——
AI味六大典型特征：
| 特征 | 表现 |
|---|---|
| 过度结构化 | 什么内容都要列点、分级 |
| 逻辑线性平坦 | 首先其次最后，没有详略取舍 |
| 词汇重复单调 | 同一个词反复出现 |
| 标点过于精准 | 每句话都完美闭合，没有口语的自然松散 |
| 案例泛化空洞 | "许多企业""大量实践"，没有具体对象 |
| 语言过于书面化 | "古色古香""跌宕起伏""无微不至"不会出现在专业文档中 |
去除方法包括：删除总结性套话、去除口语化比喻和玩梗、量化"显著提升"类表述、文艺标题改平实标题。调研文档里还有"三层叠加法"通用去AI味prompt模板和来源链接——这些全部变成Skill的规则。
第二步：让AI创建Skill。直接对Claude Code说：
我需要在本地的 .claude 目录中创建一个 cn-docx 的 skill，
结合上面的MD文档（调研结果）。这个skill的作用是去除
MD或者DOCX文档中的AI味，并使用docx来输出对应的DOCX文档。
text
还可以在后面追加一句"参考我给你的DOCX模板"并附上公司模板。Skill会解析模板里一级标题、二级标题的字号字体和表格样式，按这个标准输出，格式更贴近公司内部规范。
第三步：应用。用AI生成PRD后直接调用：
/cn-docx 处理前面的PRD文档，输出为 示例.docx
text
Skill先做AI味审查（输出删除/改写对照），再转换格式输出Word文档——字体字号按规范调整，AI味描述被去除。对照修改结果反过来调整Skill规则，几轮之后就固化成你自己的场景专用工具。
Skill的文件结构
创建完成后（依赖 npm install -g docx），Skill目录长这样：
~/.claude/skills/cn-docx/
├── SKILL.md # 主文件（触发条件 + 工作流程：读取源文件 → AI味审查 → 生成文档）
└── references/ # 参考资料目录
├── de-ai-rules.md # 去AI化规范（来自调研：六大特征 + 改写规则）
└── docx-js-cn.md # docx-js 转换工具代码
text
Skill vs 内置 Skill 的区别：
| 对比项 | /docx（内置） | /cn-docx（第三方） |
|---|---|---|
| 来源 | Claude Code 内置 | 需手动安装 |
| 功能 | Markdown → Word | Markdown → 国标Word + 去AI化 |
| 适用场景 | 所有Word文档 | 对外交付的专业文档 |
| 去AI化 | 不做 | 自动处理AI语气词 |
什么时候需要去AI化
| 场景 | 是否需要去AI化 | 原因 |
|---|---|---|
| 内部技术方案 | 否 | 只要内容准确，格式影响不大 |
| 团队知识库文档 | 否 | 清晰即可 |
| 客户交付方案 | 是 | 需要专业文档形象 |
| 投标书 | 是 | 需要符合甲方文档规范 |
| 对外API文档 | 否 | 开发者关注内容而非措辞 |
扩展场景：涉密文档脱敏
同一套"Skill定制"思路还能覆盖更严格的场景：政府、军队类文档要求脱敏——文中不得出现"绝密""加密"等涉密词汇，同时格式要满足国标和用户的定制规范。这类场景的完整方案是本地化模型 + 定制Skill：文档不能出内网，云端API不可用，用Ollama等本地推理承接模型侧（本地化部署见第19章），脱敏规则和格式规范固化进Skill，在本地完成整个"脱敏→规范化→导出"流水线。
实战示例
假设你已经用AI生成了一份客户交付的技术方案，先转换为/cn-docx格式：
/cn-docx 请将以下技术方案转换为符合国标规范的Word文档：
【你的方案内容】
要求：
1. 使用宋体小四号字
2. 首行缩进2字符
3. 章节标题用黑体
4. 一级标题三号，二级标题小三号
5. 段落间距1.5倍
6. 去除AI生成的语气词（"值得注意的是"、"显而易见"等）
text
/cn-docx会做三件事：
- 格式规范：应用国标要求的字体、字号、行距、缩进
- 语言去AI化：把AI特有的表达方式替换为中文技术文档的惯用语
- 结构优化：添加封面、目录、页眉页脚等正式文档元素
改写示例见前文"AI味长什么样"一节，核心动作就三个：删总结套话、换平实表达、把"有效提升"量化成具体数字。
local-search配合文档写作
文档里经常需要引用外部信息：竞品的API设计、最新的技术版本、市场价格数据。这些内容AI的训练数据可能过时或缺失，需要用搜索工具实时获取。
竞品信息搜索
写PRD时要对比竞品，用/local-search获取最新信息：
/local-search 搜索 Element Plus 和 Naive UI 的最新组件清单，
我需要知道它们分别有多少个组件、哪些是核心组件、
两者的组件覆盖范围有什么差异。
text
搜索结果会给你最新的组件数量和分类，你可以在PRD中引用：
## 竞品分析
| 组件库 | 组件数量 | 核心组件 | 特色 |
|--------|---------|---------|------|
| Element Plus | 50+ | Table/Form/DatePicker | 功能完整，包体积大 |
| Naive UI | 80+ | 数据展示组件 | TypeScript原生，文档详细 |
| Vue UI（我们的方案） | 15-20（MVP） | 表单+反馈组件 | 轻量，按需引入 |
我们的定位是：比Element Plus更轻，比Naive UI更简单。
markdown
技术文档查询
写技术方案时要确认API用法，用Context7 MCP查最新文档：
通过Context7查询 Vue 3.5 的 defineModel 最新用法，
我需要在技术方案中说明为什么选择 defineModel 而不是传统的 props + emit。
text
Context7会返回最新的API文档和示例代码，你可以直接引用到技术方案中。
数据和事实验证
文档中涉及的事实数据要验证，避免AI"编造"：
/local-search 查询 2026年 Vue 3、Vite、TypeScript 的最新稳定版本号，
我需要确认技术方案中的版本信息是否准确。
text
搜索结果告诉你Vue 3.5、Vite 8、TypeScript 7 等版本号，更新技术方案中的版本信息。
文档模板库
以下是几个常用的文档模板，可以直接喂给AI使用。
PRD文档模板
# [项目名称] 产品需求文档
## 一、项目背景
- 为什么做这个项目
- 要解决什么问题
## 二、产品定位
- 目标用户是谁
- 核心价值是什么
- 与竞品的差异化
## 三、功能清单
| 功能模块 | 优先级 | 预期收益 |
|---------|--------|---------|
| ... | P0/P1/P2 | ... |
## 四、用户故事
作为[角色]，我希望[功能]，以便[价值]
## 五、非功能需求
- 性能要求
- 兼容性要求
- 安全要求
## 六、成功标准
- 什么指标算成功
- 如何衡量
markdown
技术方案模板
# [项目名称] 技术方案
## 一、背景和目标
- 项目背景
- 技术目标
## 二、技术选型
| 技术 | 选型 | 版本 | 理由 |
|------|------|------|------|
| ... | ... | ... | ... |
## 三、架构设计
- 整体架构图（用Mermaid）
- 模块划分
- 依赖关系
## 四、核心实现
- 关键技术点
- 实现方案
## 五、测试策略
- 单元测试
- 集成测试
- E2E测试
## 六、风险评估
| 风险 | 影响 | 应对方案 |
|------|------|---------|
| ... | ... | ... |
## 七、开发计划
- 阶段划分
- 时间线
- 里程碑
markdown
API文档模板
# [组件/接口名称] API文档
## 概述
- 组件/接口用途
- 适用场景
## Props/参数
| 参数名 | 类型 | 默认值 | 必填 | 说明 |
|--------|------|--------|------|------|
| ... | ... | ... | ... | ... |
## Events/返回值
| 事件/字段 | 类型 | 说明 |
|----------|------|------|
| ... | ... | ... |
## Slots/子元素
| 插槽/元素 | 说明 |
|----------|------|
| ... | ... |
## 使用示例
### 基础用法
\`\`\`vue
\`\`\`
### 高级用法
\`\`\`vue
\`\`\`
## 注意事项
- ...
markdown
开发者常见错误
写AI文档生成时的常见错误：
| 错误做法 | 正确做法 | 原因 |
|---|---|---|
| 提示词太笼统："帮我写个PRD" | 给结构化要求："请写PRD，包含背景、定位、功能清单等7个章节" | AI需要明确的结构才能输出有用内容 |
| 不检查就导出Word | 先生成Markdown检查确认，再用/docx导出 | 修改Word比修改Markdown麻烦 |
| 所有文档都用/cn-docx去AI化 | 只对对外交付文档去AI化，内部文档清晰即可 | 去AI化有时间成本，没必要对所有文档都做 |
| 直接用AI生成的事实数据 | 用local-search验证版本号、价格、发布时间等 | AI的训练数据可能过时 |
| 一次性生成超长文档 | 分段生成，先生骨架再逐章展开 | 一次性生成容易遗漏细节，且难以控制质量 |
本节要点
- AI写文档的核心价值是把格式排版交给AI，你只关注内容决策
- /docx Skill可以导出符合规范的Word文档，支持标题、表格、目录；对齐公司模板的关键提示词是"复制一份原DOCX，在原文档基础上直接编辑"
- /doc-coauthoring Skill提供协作式写文档工作流：传递上下文（约十个问题收集）→迭代完善→验证可读性
- /cn-docx Skill用于对外交付文档的去AI化处理，内部文档不需要；AI味六大特征：过度结构化、逻辑线性平坦、词汇重复单调、标点过于精准、案例泛化空洞、语言过于书面化
- 自建Skill的通用方法论：local-search调研→把调研结果交给AI固化成Skill→使用中持续迭代，最终形成场景专用工具
- 涉密文档场景=本地化模型+定制Skill：脱敏规则与国标规范固化进Skill，全流程不出内网
- 文档中的事实信息用local-search和Context7验证，避免AI编造过时数据
- 使用结构化提示词，明确告诉AI文档的章节结构和输出要求
- 先生成Markdown检查确认，再导出Word，修改成本更低
- 几个常用模板（PRD、技术方案、API文档）可以直接复用
↑